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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes the Service Change and UDI Fallback (SCUDIF) feature. This service is available to 
UDI/RDI multimedia calls and allows users to achieve successful call establishment when end to end circuit-switched 
(CS) multimedia is not possible (fallback to speech) or when signalling of the feature is not possible in the network 
(fallback to preferred service or speech). Furthermore, it allows the users to swap between a multimedia service and 
basic speech during an established call. 

NOTE: In the present document, the term "multimedia" refers to UDI/RDI multimedia unless specifically stated. 



2 References 

The following documents contain provisions, which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23.153: "Out of Band Transcoder Control; Stage 2". 

[3] 3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification; Core network protocols; 

Stage 3". 

[4] 3GPP TS 26.103: "Speech Codec List for GSM and UMTS". 

[5] 3GPP TS 27.001 : "General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS)". 

[6] 3GPP TS 29.007: "General requirements on interworking between the Public Land Mobile 

Network (PLMN) and the Integrated Services Digital Network (ISDN) or Pubhc Switched 
Telephone Network (PSTN)". 

[7] 3GPP TS 29.205: "Application of Q. 1900 series to bearer-independent circuit-switched core 

network architecture; Stage 3". 

[8] 3GPP TS 22.101: "Service aspects; Service principles". 

[9] 3GPP TS 33.106: "3GPP Security; Lawful Interception Requirements". 

[ 1 0] 3GPP TS 23 .0 1 8 : "Basic Call Handling; Technical realization" . 

[II] 3GPP TS 23 .003 : "Numbering, adressing and identification" . 

[12] 3GPP TS 29.232: "Media Gateway Controller (MGC) - Media Gateway (MGW) Interface; 

Stage 3". 

[13] 3GPP TS 26.102: "Mandatory Speech Codec; AMR Speech Codec; Interface to lu, Uu, Nb". 

[14] 3GPP TS 23.078: "Customised AppHcations for Mobile network Enhanced Logic (CAMEL) ; 

Stage 2". 

[15] 3GPP TS 23.082: "Call Forwarding (CF) supplementary services. Stage 2". 
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[16] 3GPP TS 22.078: "Customised Applications for Mobile network Enhanced Logic (CAMEL); 

Service description, Stage 1". 

[17] 3GPP TS 25.413: "UTRAN lu interface RANAP signalling". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply: 

fallback: when two services (multimedia and speech) are proposed but only one of them is available or wanted, only 
the service available (preferred or less preferred) is selected, and the other one is discarded 

service change: when two services (multimedia and speech) are available during the active state of a call, users may 
request a service change to switch between the two services 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply: 

BC Bearer Capability 

BCl First Bearer Capability in a message (preferred service) 

BC2 Second Bearer Capability in a message (less preferred service) 

BCa Bearer Capability of the currently selected service 

BCb Bearer Capability of the service to switch to 

BCmm Bearer Capability multimedia 

BCSM Basic Call State Model 

BCsp Bearer Capability speech 

CAMEL Customised Applications for Mobile network Enhanced Logic 

DP Detection Point 

IE Information Element 

MMI Man-Machine Interface 

O-MSC Originating MSC 

OoBTC Out-of-Band Transcoder Control 

O-UE Originating UE 

RI Repeat Indicator 

SCUDIF Service Change and UDI/RDI Fallback 

T-MSC Terminating MSC 

T-UE Terminating UE 

4 Service ciiange and fallback for UDI/RDI multimedia 



4.1 General Requirements 



The Service Change and UDI Fallback (SCUDIF) is a function which applies to UDI/RDI multimedia calls (see 
3GPP TS 22.101 [8], clause 7.2.1), and shall support the following: 

a) Fallback to speech during call setup: allow a user to attempt to set up a multimedia call, and try a speech 
connection if the former doesn't succeed; 
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b) Fallback to the less preferred service (speech or multimedia) during call setup: allow the terminating side via 
specific settings for this service in the terminal to accept or reject a multimedia call, without interrupting the call 
setup; 

c) Fallback to the preferred service (speech or multimedia) or speech during call setup: allow the call setup to 
proceed with a single service if the transit network does not support the signalling of this functionality; 

d) BC negotiation at the terminating side: allow the terminating side via specific settings for this service in the 
terminal to turn a speech call (with service change) into a multimedia call and vice-versa; 

e) Service change: allow a speech call to be turned to multimedia by either of parties, and back to speech, through a 
successful in call modification procedure; 

f) Allow any of the users to reject a multimedia request from the other party while in speech mode. 

g) Network-initiated service change: The network shall initiate a sevice-change from multimedia to speech during 
the active call if a multimedia call can no longer be supported. If a multimedia call can again be supported at a 
later point in time, the network may initiate a service change from speech to multimedia. 

To fulfil: 

• service request signalling between the UE and the MSC; 

• service request signalling across the Core Network. 

This functionality is not supported for multimedia with Fixed Network User Rate set to 32 kbit/s. In this case, the MSC 
shall revert to a multimedia only call. 

4.2 Access Call Control Signalling 

Using the repeat indicator value "support of service change and fallback", as described in 3GPP TS 24.008 [3], 
clause 5.3.6, together with two BC-IEs, a multimedia and a speech, it is possible to request a service change and 
fallback functionality, while still maintaining the backwards compatibility with non-supporting terminals. 

4.2.1 IVIobile originating side - initiation of call setup 

By sending a SETUP message with a Repeat Indicator set to "support of service change and fallback", a multimedia 
BC-IE, and a speech BC-IE (see figure 4.1), a terminal may request a call to be set with the capability to fallback to 
either a speech only, a multimedia only call or to use service change later during the active state of the call (the first 
BC-IE indicates the preferred service). 

After checking the provisioning (see subclause 4.2.1.1), and verifying that the functionality is supported, the MSC 
replies in the CALL PROCEEDING message with either the two BCs in the same order (to indicate that it accepts the 
proposed settings - see figure 4.2), or with a single BC (multimedia or speech - see figure 4.3) unless the CALL 
PROCEEDING is delayed until the response from the terminating user and then it may also be sent with the BCs in 
reverse order (see clause 4.2.3). 

In the case the MSC ignores the SETUP message if the presence of a reserved value for the Repeat Indicator is set, it 
sends a STATUS message back to the UE (see figure 4.4), with the Cause Value set to #100, "Conditional IE error" (see 
3GPP TS 24.008 [3], clause 8.7.2). The UE then reacts as described in 3GPP TS 24.008 [3], clause 5.5.3.2.2, and may 
resend a new SETUP message with a single BC, or perform any appropriate action according to its implementation. 
This also applies in case the MSC returns instead a RELEASE COMPLETE message. 



0-UE 



0-MSC 



SETUP (Rl, BC1, BC2) 



Figure 4.1 : SETUP message towards the originating IVISC 
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0-UE 


CALL PROCEEDING (Rl, BC1, BC2) 


0-MSC 












* 









Figure 4.2: Normal case 



O-UE 




0-MSC 






CALL PROCEEDING (BC1 or BC2) 








* 









Figure 4.3: Fallback case 



O-UE 



STATUS (Cause:#1 00) 



SETUP (BCI or BC2) 



CALL PROCEEDING (BC) 



0-MSC 



NOTE 



NOTE 



NOTE: The sending of the STATUS message from the MSC and the second SETUP message from the UE are 
implementation dependent. 

Figure 4.4: IVISC not supporting the Rl value 



4.2.1.1 



Subscription checking 



The functional behaviour of the originating MSC and VLR is specified in 3GPP TS 23.018 [10]. The procedure specific 
to SCUDIF is specified in this subclause: 

For mobile originated SCUDIF calls, the MSC shall convert both PLMN bearer capability 1 and PLMN bearer 
capability 2 to two individual Basic Service codes and send them in Send Info For Outgoing Call. The VLR shall check 
the subscription for those basic services, then indicates the availability of each basic service to the MSC by Complete 
Call. If both services are not provisioned, the VLR shall send Send Info For Outgoing Call negative response to the 
MSC. The MSC shall fall back to the allowed service if the availability of only one service is indicated. The MSC shall 
continue as a SCUDIF call if the availability of both services is indicated. 



4.2.1.1.1 



Send Info For Outgoing Call 



Send Info For Outgoing Call contains the following SCUDIF specific information elements: 



Information element name 


Status 


Description 


Bearer service2 


C 


Bearer service 2 required for the IVIO call, derived from the PLMN 
bearer capability 2 information received in the set-up request from 
the MS. For a SCUDIF call, one of bearer service 2 or teleservice 
2 shall be present. 


Teleservice2 


C 


Teleservice 2 required for the MO call, derived from the PLMN 
bearer capability 2 information received in the set-up request from 
the MS. For a SCUDIF call, one of bearer service 2 or teleservice 
2 shall be present. 
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4.2.1.1.2 



Complete Call 



Complete Call contains the following SCUDIF specific information elements: 



Information element name 


Status 


Description 


First service availability 


C 


Shall be present for a MO SCUDIF call if the Bearer service or 
Teleservice is allowed; otherwise shall be absent. 


Second service availability 


C 


Shall be present for a IVIO SCUDIF call if the Bearer service 2 or 
Teleservice 2 is allowed; otherwise shall be absent. 



4.2.2 Mobile terminating side 



When the terminating MSC receives a request for a multimedia call, it shall check if the called user is provisioned for 
the service (see subclause 4.2.2.1). 

The terminating MSC shall include in the SETUP message towards the UE both BC-IEs in the same order as indicated 
by the incoming request together with the Repeat Indicator set to "service change and fallback in order to invoke the 
SCUDIF functionality in the called terminal (see figure 4.5). 

The terminating UE, based on its capabilities and internal settings, may return the two BC-IEs in the same order (to 
indicate that it accepts the proposed settings - see figure 4.6), reversed order (see figure 4.7), or just one BC-IE (either 
speech or multimedia - see figure 4.8) to the terminating MSC in the CALL CONFIRMED message. 

In the case the UE ignores the SETUP message due to the presence of a reserved value for the Repeat Indicator, it sends 
a STATUS message back to the terminating MSC (see figure 4.9), with the Cause Value set to #100, "Conditional IE 
error" (see 3GPP TS 24.008 [3], clause 8.7.2). The terminating MSC shall then react according to 3GPP TS 24.008 [3], 
clause 5.5.3.2.2 and it shall send a new SETUP message with a single BC, either the preferred service BC-IE or the 
speech BC-IE (fallback to speech), depending on configuration. The call setup then proceeds accordingly. 



T-MSC 



T-UE 



SETUP (Rl, BC1, BC2) 



Figure 4.5: SETUP message towards the terminating UE 



T-MSC 




T-UE 






CALL CONFIRMED (Rl, BC1 , BC2) 

















Figure 4.6: Normal case 



T-MSC 




T-UE 






CALL CONFIRMED (Rl, BC2, BC1) 








■^ 









Figure 4.7: Reversed call setup 
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T-MSC 




T-UE 






CALL CONFIRMED (BC1 or BC2) 








■^ 









Figure 4.8: Fallback case 



T-MSC 



STATUS (Cause: #100) 



SETUP (BC1 or BC2) 



CALL CONFIRMED (BC ) 



T-UE 



Figure 4.9: UE not supporting the Rl value 



4.2.2.1 



Subscription checking 



The functional behaviour of the terminating MSC and VLR is specified in 3GPP TS 23.018 [10]. The procedure 
specific to SCUDIF calls is specified in this subclause. 

For mobile terminating SCUDIF calls, the MSC shall convert the services received in the incoming request to two 
individual Basic Service codes, and include them in Send Info For Incoming Call. The VLR shall check the subscription 
for those basic services, then indicate the availability of each basic service to the MSC by Complete Call. If both 
services are not provisioned, the VLR shall send Send Info for Incoming Call negative response to the MSC. The MSC 
shall fall back to the allowed service if the availability of only one service is indicated. The MSC shall continue as a 
SCUDIF call if the availability of both services is indicated. 

4.2.2.1 .1 Send Info For Incoming Call 

Send Info For Incoming Call contains the following SCUDIF specific information elements: 



Information element name 


Required 


Description 


Bearer Service 2 


C 


Bearer Service 2 required for the IVIT call, derived from the less 
preferred service indicated in the incoming lAIVI of a SCUDIF call. 
For a SCUDIF call, one of Bearer service 2 or Teleservice 2 shall 
be present. 


Teleservice 2 


C 


Teleservice 2 required for the IVIT call, derived from the less 
preferred service indicated in the incoming lAIVI of a SCUDIF call. 
For a SCUDIF call, one of Bearer service 2 or Teleservice 2 shall 
be present. 



4.2.2.1.2 



Complete Call 



The parameters described in subclause 4.2.1.1.2 "Complete Call" for the mobile originating MSC are also applicable to 
the mobile terminating MSC. 

4.2.3 Mobile originating side - completion of call setup 

If the preferred mode, that is the first BC-IE indicated by the originating UE, was selected as the result of negotiations, 
the call shall be set up normally towards the originating UE. 
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If the negotiation resulted in a change of the selected mode, i.e. the call was set up as "multimedia first" and changed 
during the negotiation to a speech call, or vice-versa, because of either fallback or change of selected mode and the Call 
Proceeding message has been sent then an In-Call Modification procedure (see 3GPP TS 24.008 [3], clause 5.3.4.3) 
shall be initiated towards the originating UE after the call control entity has entered the active state, i.e. the CONNECT 
message has been sent. 



0-UE 



0-MSC 



CONNECT 



CONNECT ACKNOWLEDGE 



Figure 4.10: Preferred mode selected 



O-UE 



CONNECT 



0-MSC 



CONNECT ACKNOWLEDGE 



MODIFY {BC2) 



MODIFY COMPLETE (BC2) 



Figure 4.11 : Less preferred mode selected, accepted 



O-UE 



CONNECT 



0-MSC 



CONNECT ACKNOWLEDGE 



MODIFY (BC2) 



MODIFY REJECT (BC1) 



RELEASE COMPLETE 



Figure 4.12: Less preferred mode selected, rejected 

If the Call Proceeding message is delayed until response from the terminating side then it may include one or both BCs 
either in the order requested from the Originating UE or the order of the BCs may be reversed, depending on the result 
from the negotiation or (single EC) due to fallback. See Figure 4.12a. 
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0-UE 



OALL PROCEEDING (Rl, BC2, BC1) 



0-MSC 



CONNECT 



CONNECT ACKNOWLEDGE 



(select = X, avail = x, y, z, mm) 



Figure 4.12a: Call Proceeding Delayed 



4.2.4 Service change in tine active state 



At any given time, if either of the call parties wants to change from the current active mode to the other mode via MMI, 
the terminal shall activate an In-Call Modification procedure. Using this procedure, described in 3GPP TS 24.008 [3], 
clause 5.3.4.3, the UE shall send a MODIFY message containing the BC-IE to change to. This BC-IE shall be one of 
those already negotiated at call setup. 

As a result, the MSC shall then invoke the service change procedure (see clause 4.3.5). If the request is accepted, the 
originating MSC sends a MODIFY COMPLETE message to the UE including the BC-IE of the mode to switch to (see 
figure 4.13). If the request is rejected, the MSC sends a MODIFY REJECT message to the UE including the BC-IE 
from the current active mode (see figure 4.14). 

In the case the MSC has determined that the other mode is unavailable (e.g. a fallback to either mode has occurred), it 
shall reject the MODIFY request at once by replying with a MODIFY REJECT message. 

On the remote side, the MSC shall initiate an In-Call Modification procedure towards the terminal using the MODIFY 
message. For a service change from speech to multimedia, the terminal shall request confirmation from the user unless 
configured differently. For a service change from multimedia to speech, the terminal shall accept the request without 
requesting confirmation from the user. If the change is accepted, the UE shall reply to the MSC with a MODIFY 
COMPLETE message, whereas a MODIFY REJECT message shall be sent if the change is rejected. 

NOTE: Privacy concerns strongly advise that any change to multimedia mode, unless explicitly allowed by the 

user in the terminal configuration settings, triggers a question to the user in order to confirm or decline the 
change. The details on how to provide the user interaction are left for implementation. 




MSCB 



Core Network 
Procedure 



Core Network 
Procedure 



UEB 



MODIFY (BCb) 



MODIFY COMPLETE (BCb) 



Figure 4.13: Service change requested, accepted 
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MSCB 



Core Network 
Procedure 



Core Network 
Procedure 



UEB 



MODIFY (BCb) 



MODIFY REJECT (BCa) 



Figure 4.14: Service change requested, rejected 

4.2.5 Network-initiated Service cinange in \he active state 

When the visited MSC of either party can no longer support an ongoing multimedia call, for example due to degraded 
coverage conditions (including UTRAN to GERAN only transitions), the visited MSC of this party shall initiate a 
sevice-change from multimedia to speech, following the procedures described below. 

If the visited MSC is again able to support the multimedia at a later point in time while the speech call is still ongoing, 
the same visited MSC may initiate a service change from speech to multimedia as stated in TS 22.101 [8]. The details 
for the service change from speech to multimedia are FFS. 

The visited MSC shall initiate an In-Call Modification procedure towards the terminal it serves using the MODIFY 
message. The visited MSC shall also invoke the service change procedure (see clause 4.3.5) towards the remote side. 
The terminals on both sides will react as described in Clause 4.2.4. 

If the terminal on either side rejects the service change, the visited MSC shall either clear the call, or it shall initiate a 
service change procedure towards the other side to revert to the original service. 



UEA 



MSC A 



MODIFY (BCb) 



MODIFY COMPLETE (BCb) 



Core Network 
Procedure 



Core Network 
Procedure 



MSCB 



UEB 



MODIFY (BCb) 



MODIFY COMPLETE (BCb) 



Figure 4.14a: Networit-lnitiated Service change from multimedia to speech requested, accepted 



Figure 4.14b: void 



Figure 4.14c: void 
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4.2.5.1 Network-initiated Service change in the active state starting with multimedia 

in lu mode 

For a network initiated service change from multimedia in lu mode to speech, the visited MSC shall use the following 
procedure. 

In order to request a notification from the RNC when it detects a lack of sufficient resources or radio signal degradation, 
the visited MSC shall include an Alternative RAB Parameters IE in the RANAP RAB Assignment Request or RANAP 
Relocation Request message indicating the RAB configuration for speech in addition to the RAB configuration for 
multimedia when it establishes or modifies the radio access bearer for multimedia at the lu interface. 

When the radio access network detects a lack of sufficient resources to sustain the multimedia RAB configuration, it 
shall inform the visited MSC by sending a RANAP Modify Request message (see 3GPP TS 25.413 [17]) to the visited 
MSC. The visited MSC shall then: 

initiate an In-Call Modification procedure to speech towards the terminal it serves using the MODIFY message; 
and 

invoke the service change procedure (see clause 4.3.5) towards the remote side, 

trigger the RAB modification by sending a RANAP RAB Assignment with the RAB requested to be Modified to 
the RNC. 



UEA 




RNC A 



MSC A 



RANAP RAB Assignment 

(configurationl, configuration 2) 



RANAP Modify Request 
(alternate configuration requested) 



MODIFY 

(BCspeech) 



MODIFY COMPLETE 
(BCspeech) 



RAB Assignment Modify 
(Configuration 2, Configurationl) 



MSCB 



Core Network 
Procedure 



UEB 



MODIFY 
(BCspeech) 



MODIFY COMPLETE 
(BCspeech) 



Figure 4.1 4d: Network-Initiated Service change from UTRAN multimedia to speech requested, 

accepted 



4.3 Core Network procedures 



In order to provide the capability in the network to transmit the request for service change and fallback both at call setup 
and during the active state of a call, the normal Out-of-Band Transcoder Control procedures, described in 
3GPP TS 23.153 [2] shall be used. The following text describes the codec to be used, the mapping between the terminal 
interface described above, and the different IBs to be used for the codec negotiation procedures at both the originating 
and the terminating MSC. 
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4.3.1 Multimedia codec 

The codec negotiation procedures transmit an ordered list of preferred codecs from the originating to the terminating 
MSC. A node that requires interaction with the user plane will remove the codecs it does not support. The terminating 
MSC shall select the codec to use ("selected codec") from the list of available codecs for the call. This selection shall be 
based on the received list of codecs and on the information given by the terminating UE in the CALL CONFIRMED 

message. 

A dummy codec (defined in 3GPP TS 26.103 [4]) is included in the codec list to indicate that a multimedia call is 
requested. This codec is in the present document referred to as the 3G-324.M codec. 

This codec is only used by the Core Network and shall not be sent from the terminal in the Supported Codec List IE. 
The 3G-324.M codec shall be indicated to the MGW as codec media stream property in accordance with the3GPP TS 
29.232[12]. The MGW shall treat the User Plane configuration (SDU Format) of the 3G-324.M codec as for PCM, as 
defined in 3GPP TS 26.102 [13]. 

4.3.2 Originating side - initiation of call setup 

The originating MSC has a list of supported codec types, listed in order of preference. 

If the SETUP message received from the UE contains a Repeat Indicator with a value of "service change and fallback", 
in addition to a multimedia BC-IE and a speech BC-IE, the MSC shall include a 3G-324.M codec in the list of 
supported codec types according to the following rule: 

• if the multimedia BC-IE is listed first, then the 3G-324.M codec shall be the first codec in the list (see 
figure 4.15); 

• if the speech BC-IE is listed first, then the 3G-324.M codec shall be the last codec in the list (see figure 4. 16). In 
the case that the maximum number of codecs is already reached before insertion of the 3G-324M codec, the 
optional speech codec with the least preference shall be replaced by the 3G-324.M codec. 

The list shall then be sent according to the Out-of-Band Transcoder Control codec negotiation procedures. The TMR 
field, although mandatory BICC/ISUP parameter, has no meaning when using OoBTC/BICC codec negotiation (the 
link characteristics and QoS are determined from the codec type and signalled to any intermediate switches via the 
bearer control protocol) and thus shall be set arbitrarily to "speech". A transit node that requires interaction with the user 
plane will remove from the list the codecs it does not support. If the 3G-324.M codec is not supported, and thus 
removed, the call shall be turned into a normal speech call (fallback to speech) and follow the normal call setup 
procedures. 



0-UE 



0-MSC 



SETUP (Rl, BCmm, BCsp) 



T-MSC 



(List of Codecs = mm, x, y, z) 



X, y, z: speech codecs. 

mm: dummy multimedia codec. 



Figure 4.15: Multimedia BC as first BC 
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0-UE 



0-MSC 



SETUP (Rl, BCsp, BCmm) 



T-MSC 



(List of Codecs = x, y, z, mm) 



Figure 4.16: Speech BC as first BC 



4.3.3 Terminating side 



4.3.3.1 



HLR Interrogation 



The GMSC sends the Send Routing Information request with both the Network Signal Information and Network Signal 
Information 2 parameters. The Network Signal Information shall include the ISDN BC IE for the preferred service, and 
the Network Signal Information 2 includes the ISDN BC IE for the less preferred service. 

The functional behaviour of the HLR is described in 3GPP TS 23.018 [10]. The procedures specific to SCUDIF calls 
are specified in the subclause 4.3.3.1.3 for the HLR and 4.3.3.1.4 for the GMSC. The information elements specific to 
SCUDIF between the GMSC and the HLR are specified in subclauses 4.3.3.1.1 and 4.3.3.1.2. 

4.3.3.1.1 Send Routing Info 

The following element specific to SCUDIF calls is defined for Send Routing Info: 



Information element name 


Required 


Description 


ISDNBC2 


C 


ISDN bearer capability 2. Shall be present for a SCUDIF call to 
indicate the less preferred service. 


ISDN LLC 2 


C 


ISDN lower layer compatibility 2. Shall be present for a SCUDIF 
call if necessary for the less preferred service, otherwise shall be 
absent. 


ISDN HLC 2 


c 


ISDN higher layer compatibility 2. Shall be present for a SCUDIF 
call if necessary for the less preferred service, otherwise shall be 
absent. 



4.3.3.1 .2 Send Routing Info Ack 

The following elements specific to SCUDIF calls are defined for Send Routing Info Ack: 
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Information element name 


Required 


Description 


Roaming number 2 


C 


E.164 number required to route the call to VMSCB (see 3GPP 
TS 23.003 [11]) for the less preferred service of a SCUDIF call. 
Shall be present for a SCUDIF call if the preferred service is not 
forwarded {i.e. either Roaming Number is present or the preferred 
service is not allowed) and the less preferred service is allowed 
and not forwarded, otherwise shall be absent. 


Forwarded-to number 2 


C 


E.164 number of the C subscriber for the less preferred service of 
a SCUDIF call. Shall be present if the HLR has determined that 
the less preferred service of a SCUDIF call is to be forwarded, 
otherwise shall be absent. 


Long forwarded-to number 2 


C 


Number of the C subscriber (see 3GPP TS 23.082 [1 5]) for the 
less preferred service of a SCUDIF call. Shall be present if the 
HLR has determined that the less preferred service of a SCUDIF 
call is to be forwarded, and GMSC and HLR support Long 
Forwarded-to Numbers, otherwise shall be absent. 


Forwarded-to subaddress 2 


c 


Subaddress of the C subscriber (see 3GPP TS 23.003 [1 1 ]) for the 
less preferred service of a SCUDIF call. Shall be present if the 
HLR has determined that the less preferred service of a SCUDIF 
call is to be forwarded and a forwarded-to subaddress is stored in 
the HLR in association with the forwarded-to number 2, otherwise 
shall be absent. 


Notification to calling party 2 


c 


Indication of whether the calling party is to be notified that the call 
has been forwarded if the less preferred service of a SCUDIF call 
is kept. Shall be present if the HLR has determined that the less 
preferred service of a SCUDIF call is to be forwarded, otherwise 
shall be absent. 


Forwarding reason 2 


c 


Indication of why the call has been forwarded (unconditionally or 
on mobile subscriber not reachable) for the less preferred service 
of a SCUDIF call. Shall be present if the HLR has determined that 
the less preferred service of a SCUDIF call is to be forwarded, 
otherwise shall be absent. 


SS-List 2 


c 


List of SS-codes for the less preferred service of a SCUDIF call. 
Shall be present if the HLR has determined that the less preferred 
service of a SCUDIF call is allowed, otherwise shall be absent. 


Basic Service Code 2 


c 


Indicates the type of the basic service for the less preferred 
service, i.e. teleservice or bearer service. 


Allowed Services 


c 


Shall be present for SCUDIF calls. Indicates which services are 
available for that call. 


Unavailability Cause 


c 


Indicates the reason for which one of the services of a SCUDIF 
call is not available. Shall be present for SCUDIF calls if one 
service is not available. 



4.3.3.1 .3 Handling of mobile terminating calls in the HLR 

The procedures specific to SCUDIF calls in the HLR are specified within this subclause: 

- Procedure SCUDIF_Subscription_Check_HLR 

- Procedure SCUDIF_CAMEL_CSI_Check_HLR 
Procedure SCUDIF_Set_Second_Service_when_Forwarded 

- Procedure SCUDIF_Set_Correct_PLMN_BC 

Procedure SCUDIF_Check_Second_Service_before_Negative_Response 

- Procedure SCUDIF_Check_Second_Service_after_PRN 
Procedure SCUDIF_Check_Second_Service_when_Forwarded 
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procedure SCUDIFSubscriptionCheckHLR 

: Procedure in Itie HLR to clieck Itie subscription for the second : '•. 
I service and store tlie unavailability cause if one of the services ''"\ 
lis not available : 



Allowed Services : 
botti 



6 




store Resultfor 
first service 




Jr^vail ability Cause:: 
negative response 



Allowed Services :■- 
second Service 



requested service 
■Jetwork Signal Info 2 



_6 



SCSC_HLR1(2) 



Figure 4.1 6A: Procedure SCUDIF_Subscription_Check_HLR (sheet 1) 
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procedure SCUDIFSubscriptionCheckHLR 

: Procedure in Itie HLR to clieck Itie subscription for the second : '•. 
I service and store tlie unavailability cause if one of the services ''"\ 
lis not available : 



SCSC_HLR2(2) 



o 



ub script ion_Ctieck 
HLR 




J na vail ability Caust 
negative respons 



legative response :- 
legative response foi 
first service 



Allowed Services :■ 
first Service 



Figure 4.16B: Procedure SCUDIF_Subscription_Check_HLR (sheet 2) 
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procedure SCUDIF_CAMEL_CSI_Check_HLR 



: Procedure in Itie HLR to clieck : *•, 

Itlie CAMEL data for the second serviced 
i to know if CAMEL is active for that call : 



CO 



CAMEL_CSI. 
iUbscription_Chec 



1(1) 



■■: for second service 



Figure 4.16C: Procedure SCUDIF_CAMEL_CSI_Check_HLR 
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procedure SCUDIF_Set_Second_Service_when_forwarded 



: Procedure in the HLR to set tine forwarding :\ 
i intormation to the correctservice for SCUDlP^ 



(O 




store Forwarding 

nformation for secon( 

Service 



Store Forwarding 

Information for first 

Service 



result := SRI_Ack 



result := continue 



1(1) 



Figure 4.16D: Procedure SCUDIF_Set_Second_Service_when_Forwarded 
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procedure SCUDIF_Set_Correct_PLMN_BC 

iProcedure in the HLR to i':-. 

iset the speech PLMN BC i 

iSCUDIF calls : 



QJ) 




yes 




CoDy 



I MSRN for 
! to MSRN 



result :=SRLA(k 



1(1) 



yes 



PLMN BC ;= 
BCfor 

piaiar[-| c;ia[-y jrg 



PLMN BC := 

BCfor 
lower;! .servfici 



result := 
continue 



result := 
! et_PLMN_BC 




Figure 4.1 6E: Procedure SCUDIF_Set_Correct_PLMN_BC 
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procedure SCUDIF_Check_second_service_before_Negative_response 



: Procedure in Itie HLR to cliecl< fine second service : *•, 

I before sending a SRI negative response back to the GMSC^ 



(O 




restore routeing 
information for 
first service 




negative response : 

negative response 

for first service 



jnavailability cause : 
negative response 



allowed services :■ 
first service 




requested service : 
second signal 
network info 



jnavailability cause : 
negative response 



result :- second 
interrogation 



1(1) 



Figure 4.1 6F: Procedure SCUDIF_Check_Second_Service_before_Negative_Response 
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procedure SCUDIF_Check_Second_Service_after_PRN 



1(1) 



: Procedure in fine HLR to check :\ 

I the secorxJ service after PRNrespor^H^ 
ihas been received i 



(U) 



store routeing 

information for the 

tirst service 



requested service : 

second network 

signal info 



second interrogation 



Store routeing 
information for the 
second service 



Figure 4.16G: Procedure SCUDIF_Check_Second_Service_after_PRN 
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procedure SCUDIF_Check_Second_Service_when_forwarded 



1(1) 



: Procedure in Itie HLR to check :\ 
I the secorxJ service when a service fe^ 
: forwarded i 



(U) 



store routeing 

information for the 

first service 



requested service 
Network Signal Info 2 



second interogation 



second service 



resUt:= continue 



Figure 4.16H: Procedure SCUDIF_Check_Second_Service_when_Forwarded 

4.3.3.1 .4 Handling of mobile terminating calls in the GMSC 

The procedures specific to SCUDIF calls in the GMSC are specified within this subclause: 
Procedure SCUDIF_Negative_SRI_Response_Handling 
Procedure SCUDIF_Check_Service_Availability 
Procedure SCUDIF_Check_Service_Compatibility 



ETSI 



3GPP TS 23.172 version 6.2.0 Release 6 



26 



ETSI TS 123 172 V6.2.0 (2005-03) 



procedure SCUDIF_Negative_SRI_Response_Handling 



SC_SRI1(1) 



: Procedure in fine GMSC to handle : '•. 

I a second interrogation for SCUDIF '"\ 
I call when a negative response is received : 



(U) 



Faiibackto tlie 
5S preferred servics 



[ itrieve SRI result frorp 
first interrogation 



Figure 4.161: Procedure SCUDIF_Negative_SRI_Response_Handling 
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procedure SCUDIF_Check_Service_Availability 

i Procedure in the GMSC to fallback to a :.\ 
; single service If one of the services i 

■of a SCUDIF call is unavailable 



SC_S_A1(1) 



(O 



No 



yes 



yes 



Value of Allowed 
services Indicator ? 

botbZ; 




Second Service ^ 



iitsl service 



=allbacl< to the 
les ; preferred se<\ 



icq[ 



fallback to the 
referred servic 



yes 



Result Is for the less 
[ referred servic 3 



Store SRI for 
referred servic 



rfsult ;=continLJe 

1^ 



resjit := second_;RI rdsult := contim.3 



Figure 4.16J: Procedure SCUDIF_Check_Service_Availability 



ETSI 



3GPP TS 23.172 version 6.2.0 Release 6 



28 



ETSI TS 123 172 V6.2.0 (2005-03) 



procedure SCUDIF_Check_Service_Compatibility 



SC_S_C1(1) 



Procedure in Itie GMSC to fallbacl^ to a 
single service if tlie services 
of a SCUDIF call liave different 
destination 




Figure 4.1 6K: Procedure SCUDIF_Check_Service_Compatibility 



4.3.3.2 



Terminating MSC Handling 



The terminating MSC receives the Hst of supported codec types, including the 3G-324.M codec. It shall then send a 
SETUP message towards the terminating UE including a Repeat Indicator with the value "service change and fallback" 
and two BC-IEs, according to the following rule: 

• if the 3G-324.M codec is the first (preferred) codec in the list of supported codecs, then the first BC-IE in the 
SETUP message is the multimedia BC-IE, and the second BC-IE is the speech BC-IE (see figure 4.17); 

• if the 3G-324.M codec is in the list of supported codec types, but not in the first position, then the first BC-IE in 
the SETUP message is the speech BC-IE, and the second BC-IE is the multimedia BC-IE (see figure 4.18). 

The terminating UE answers according to its capabilities in the CALL CONFIRMED message. The terminating MSC 
shall determine the Selected Codec and construct the list of available codecs according to the following rules: 
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• if no Repeat Indicator is included, and only a speech BC-IE is received, the MSC shall choose a speech codec as 
the Selected Codec according to the normal mechanism, and no 3G-324.M codec shall be inserted in the list of 
available codecs (see figure 4.19); 

• if no Repeat Indicator is included, and only a multimedia BC-IE is received, the MSC shall choose the 
3G-324.M codec as the Selected Codec, and only the 3G-324.M codec shall be inserted in the list of available 
codecs (see figure 4.20); 

• if the Repeat Indicator is included, and the speech BC_IE is the first BC-IE and the multimedia BC-IE is the 
second BC-IE, the MSC shall choose a speech codec as the Selected Codec according to the normal mechanism, 
and both the 3G-324.M codec and speech codecs shall be inserted in the list of available codecs (see figure 4.21); 

• if the Repeat Indicator is included, and the multimedia BC-IE is the first BC-IE and the speech BC-IE is the 
second BC-IE, the Selected Codec shall be the 3G-324.M codec, and both the 3G-324.M codec and speech 
codecs shall be inserted in the list of available codecs (see figure 4.22). 

The Selected Codec and the list of available codecs shall be sent back to the originating MSC according to the normal 
codec negotiation procedure. 



0-MSC 



T-MSC 



(List of Codecs = mm, x, y, z) 



T-UE 



SETUP (Rl, BCmm, BCsp) 



Figure 4.17: 3G-324M codec first 



0-MSC 



T-MSC 



(List of Codecs = x, y, z, mm) 



T-UE 



SETUP (Rl, BCsp, BCmm) 



Figure 4.18: Speechi codec first 



0-MSC 



T-MSC 



(select = X, avail = x, y, z) 



T-UE 



CALL CONFIRMED (BCsp) 



NOTE 



NOTE: The actual speech codec is selected according to OoBTC procedures. 

Figure 4.19: Speechi only 
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0-MSC 



T-MSC 



(select = mm, avail = mm) 



T-UE 



CALL CONFIRMED (BCmm) 



Figure 4.20: Multimedia only 



0-MSC 



T-MSC 



(select = X, avail = x, y, z, mm) 



T-UE 



CALL CONFIRMED (Rl, BCsp, BCmm) 



NOTE 



NOTE: The actual speech codec is selected according to OoBTC procedures. 

Figure 4.21 : Speech preferred 



0-MSC 



T-MSC 



(select = mm, avail = mm, x, y, z) 



T-UE 



CALL CONFIRMED (Rl, BCmm, BCsp) 



NOTE 



NOTE: The actual list of speech codecs is built according to OoBTC procedures. 

Figure 4.22: Multimedia preferred 

4.3.4 Originating side - completion of call setup 

The originating MSC receives the Selected Codec and the Hst of available codecs, and, depending on the active mode, 
shall do the following: 

The call was set up with a multimedia BC-IE first: 

• if the Selected Codec is the 3G-324.M codec, no In-Call Modification procedure is necessary (see figure 4.23). If 
no speech codecs are included in the list of available codecs, all In-Call Modification procedures initiated by the 
UE using the speech BC-IE shall be rejected with a MODIFY REJECT message; 

• if the Selected Codec is a speech codec, an In-Call Modification procedure to change to speech mode shall take 
place (see figure 4.24). If the 3G-324.M codec is not included in the list of available codecs, all In-Call 
Modification procedures initiated by the UE using the multimedia BC-IE shall be rejected with a MODIFY 
REJECT message. 

The call was set up with a speech BC-IE first: 

• if the Selected Codec is the 3G-324.M codec, an In-Call Modification procedure to change to multimedia mode 
shall take place (see figure 4.25). If no speech codecs are included in the list of available codecs, all In-Call 
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Modification procedures initiated by the UE using the speech BC-IE shall be rejected with a MODIFY REJECT 

message; 

• if the Selected Codec is a speech codec, no In-Call Modification procedure is necessary (see figure 4.26). If the 
3G-324.M codec is not included in the list of available codecs, all In-Call Modification procedures initiated by 
the UE using the multimedia BC-IE shall be rejected with a MODIFY REJECT message. 



0-UE 



0-MSC 



CONNECT 



T-MSC 



(select = mm, avail = mm, x, y, z) 



NOTE 



NOTE: Speech codecs (x, y, z) may or may not be present. If they are not present, subsequent MODIFY requests 
from the UE are rejected. 

Figure 4.23: Multimedia preferred, selected 



O-UE 



0-MSC 



CONNECT 



MODIFY (BCsp) 



T-MSC 



(select = X, avail = x, y, z, mm) 



NOTE 1 



NOTE 2 



NOTE 1 : The multimedia codec (mm) may or may not be present. If it is not present, subsequent MODIFY requests 

from the UE are rejected. 
NOTE 2: see clause 4.2.3 for the In-Call Modification signalling. 

Figure 4.24: Multimedia preferred, speech selected 



O-UE 



0-MSC 



CONNECT 



MODIFY (BCmm) 



T-MSC 



(select = mm, avail = mm, x, y, z) 



N0TE1 



NOTE 2 



NOTE 1 : Speech codecs (x, y, z) may or may not be present. If they are not present, subsequent MODIFY requests 

from the UE are rejected. 
NOTE 2: see clause 4.2.3 for the In-Call Modification signalling. 

Figure 4.25: Speech preferred, multimedia selected 
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0-UE 




0-MSC 




T-MSC 












(select = X, avail = x, y, z, mm 


) 


NO 




CONNECT 

















NOTE: The multimedia codec (mm) may or may not be present. If it is not present, subsequent MODIFY requests 
from the UE are rejected. 

Figure 4.26: Speech preferred, selected 

4.3.5 Service change during tine active state 

Whenever an In-Call Modification procedure is invoked by a terminal, unless it is not allowed as determined at call 
setup, the following shall take place: 

• if the current mode is the speech mode and the MODIFY message contains a multimedia BC-IE, the normal 
Out-of-Band Transcoder Control procedures shall be invoked in order to change the Selected Codec to the 
3G-324.M codec; 

• if the current mode is the multimedia mode and the MODIFY message contains a speech BC-IE, the normal 
Out-of-Band Transcoder Control procedures shall be invoked in order to change the Selected Codec to the 
preferred speech codec. 

When a visited MSC invokes Network-initiated Service change in the active state (see Clause 4.2.5), this visited MSC 
shall also invoke the normal Out-of-Band Transcoder Control procedures in order to change the Selected Codec to 
speech or to the 3G-324.M codec, respectively. 

The Codec Modification procedure shall be supported for service change. The use of mid-call codec negotiation 
procedure is optional for service change. 

When a MSC detects through an Out-of-Band Transcoder Control procedure that the selected codec has changed from a 
speech codec to the 3G-324.M codec, or vice-versa, it shall initiate an In-Call Modification procedure towards the UE 
with a MODIFY message containing the multimedia BC-IE (or the speech BC-IE), unless the new mode has been 
denied at call setup (see clause 4.2.4). 



4.3.5.1 



Mid-Call Codec Modification Procedure For Service Change 



The Codec Modification procedures as defined in 3GPP TS 23.153 [2] shall be applied with the following specific 
additional rules for the Service Change procedure. 

In order to prevent the MGW generating an error or seizing resources during the interim period when its terminations 
are being altered and it may have a speech codec on one side of the context and the 3G-324M codec on the other side 
the Server shall modify the Stream-mode of the affected terminations to inactive during the Service change and shall 
restore the stream mode to active - (send/receive - bothway) on completion of the service change procedure. In order to 
restore the stream mode to active, the MSC servers shall use the 'Modify Bearer Characteristics' procedure for lu 
terminations and for Nb terminations towards the succeeding node with respect to the 'Modify Codec' message. The 
MSC servers shall use the 'Confirm Bearer Characteristics' procedure for Nb terminations towards the preceding node 
with respect to the 'Modify Codec' message. 

If the affected termination"s stream mode is inactive a MGW shall not reject a 'Modify Bearer Characteristics' or a 
'Reserve Bearer Characteristics' procedure because the multimedia codec and a speech codec are interconnected 
simultaneously in the same context. 

For a service change where the CN shall initiate the luUP on the Nb interface, the MSC server terminating the service 
change shall trigger the luUP initialisation towards the core network by setting the luUP initialisation direction to 'out' 
in the 'Confirm Bearer Characteristics' procedure for the corresponding termination towards the core network. 
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Example call flows are shown in Figure 4.3.5.1/1 to 4.3.5.1/6. 
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Figure 4.3.5.1/1 : Service change speech to IVIulVIe 
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Figure 4.3.5.1/2: Service change speech to IVIulVIe (continued) 
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Figure 4.3.5.1/3: Service change IVIulVIe to AIVIR 
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Figure 4.3.5.1/4: Service chiange IVIulVIe to AIVIR (continued) 
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Figure 4.3.5.1/5: Service change lUiulUleto PCIU1(G.711) 
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Figure 4.3.5.1/6: Service change IVIulUle to PCI\fl(G.711) (continued) 



4.3.5.2 Unsuccessful Service Change 

In the case the service change is denied by the UE at the terminating side, the procedures for the unsuccessful Codec 
Modification as defined in [2] shall be applied to revert to the old medium (speech or multimedia). 

The through-connection of terminations shall be performed as described in Subclause 4.3.5.1. The "Codec Modification 
Failure" message shall interact with the "Modify Bearer Characteristics" procedure and the "Confirm Bearer 
Characteristics" procedure in the same way as the 'Successful Codec Modification' message. 

An example sequence is shown in Figure 4.3.5.2/1 to 4.3.5.2/2. 
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Figure 4.3.5.2/1 :Service Change Rejected 
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Figure 4.3.5.2/2 :Service Change Rejected (Continued) 
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4.3.6 Interaction with supplementary services 
4.3.6.1 Call forwarding and Call deflection 

If CFB(UDUB), CFNRy, or Call Deflection is invoked in a SCUDIF call, and both basic services are provisioned, the 
HLR (for early call forwarding) or VLR (for late call forwarding) shall check the handling of the call should continue 
with the active service negotiated between the called UE and the network. 

If call forwarding except CFB(UDUB) and CFNRy is invoked in a SCUDIF call, and both basic services are 
provisioned, the HLR (for early call forwarding) or VLR (for late call forwarding) shall check the service for both the 
preferred service and the less preferred service. 

Then, the SCUDIF call interacting with call forwarding shall be handled according to the following rules: 

If the call forwarding is active only for the less preferred service, the preferred service shall be selected and the 
call setup shall continue with a single service without invoking call forwarding. 

If the call forwarding is active only for the preferred service, the preferred service shall be selected and call 
forwarding shall continue with a single service to the destination indicated by the forwarded to number. 

If the call forwarding is active for both services and the forwarded to number for the preferred service is same as 
for the less preferred service, the call shall continue as a SCUDIF call to the destination indicated by the 
forwarded to number. 

If the call forwarding is active for both services and the forwarded to number for the preferred service is different 
from that for the less preferred service, the preferred service shall be selected and call forwarding shall continue 
with a single service to the destination indicated by the forwarded to number for the preferred service. 

If the call forwarding is active for both services and CF type for the preferred service is different from that of 
less preferred service, the call shall continue as a SCUDIF call to the destination indicated by the forwarded to 
number, and the forwarding reason for the preferred service shall be indicated. 

NOTE: For Late call forwarding or Call Deflection with Optimal Routing, the second basic service group code 
shall be generated in VMSC and sent in Resume Call Handling and may be sent in the following Send 
Routing Information. The preferred service is set as basic service group IE, and the less preferred service 
is set as basic service group 2 IE. 



4.3.6.2 Closed User Group (CUG) 

If a SCUDIF call interacts with CUG and both basic services are provisioned, the service state shall be checked for both 
the preferred service and the less preferred service. If one service is not allowed, then the call shall fall back to the 
allowed service. 

4.3.6.3 Call barring 

If a SCUDIF call interacts with call barring and both basic services are provisioned, the service state shall be checked 
for both the preferred service and the less preferred service. If one service is barred, then the call shall fall back to the 
allowed service. 

4.3.7 Interactions with CAMEL 
4.3.7.1 Interaction at call setup 

When a SCUDIF call activates a CAMEL dialogue for the originating or the terminating subscriber, both basic services 
shall be indicated to the gsmSCF in the InitialDP message (see 3GPP TS 23.078 [14]) : 

• the bearer capability IE and the ext-basic service code IE shall indicate the preferred service (i.e. 3G-324.M if the 
3G-324.M codec is the first codec in the list of supported codecs ; speech otherwise). 
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• the bearer capability 2 IE and the ext-basic service code 2 IE shall indicate the other, less preferred service (i.e. 
resp. speech or 3G-324.M). 

4.3.7.2 Interaction at call answer 

When the Answer DP is triggered according to the BCSM (see 3GPP TS 23.078 [14]), the event report sent to the 
gsmSCF shall indicate the result from the OoBTC codec negotiation procedure according to the following : 

• the ext-basic service code IE is included, and represents the selected service (indicated by the selected codec) ; 

• the ext-basic service code 2 IE is included if the list of available codecs contains codecs both for speech and 3G- 
324.M, and represents the other service (i.e. speech if the selected service is 3G-324.M, and vice-versa). 

4.3.7.3 Interaction with Call Party Handling 

Interaction with Call Party Handling is allowed, when the call is a speech call and it cannot become a multimedia call. 
See 3GPP TS 22.078 [16] clause 21. 

4.3.7.4 Interaction with CAMEL in-band information and user interaction 

Interaction with Camel in-band information and user interaction is allowed, when the call is a speech call and it cannot 
become a multimedia call. 

See 3GPP TS 22.078 [16] clause 21. 

4.3.7.5 Interaction during service change 

When a service change is successfully completed (i.e. the codec modification or mid-call codec negotiation reply 
message indicates a successful codec modification), and the 0_Service_Change DP or the T_Service_Change DP is 
armed, then the relevant detection point is triggered (see 3GPP TS 23.078 [14]). 

When a service change is rejected (i.e. the codec modification or mid-call codec negotiation reply message indicates a 
failure), then the previously selected service is kept, and no event report shall be sent to the gsmSCF for the 
0_Service_Change DP and the T_Service_Change DP. 



4.3.8 Interworking with external networks 

If the 3G-324.M codec is included in the list of supported codec types received by a Gateway MSC, and the external 
network does not support BICC or does not support Codec Negotiation, the Gateway MSC shall terminate the codec 
negotiation and fallback to a single service. 

NOTE 1 : If the route is known not to support the SCUDIF functionality, the Gateway MSC may decide by 
configuration to terminate the codec negotiation and follow the procedure described in this clause. 

In the case where the 3G-324.M codec is the first in the list, the network decides by configuration to fallback either to a 
UDI multimedia-only call or to speech. In the case where the 3G-324.M codec is not the first on the list, the call shall 
fallback to speech only. 

If fallback to multimedia occurs, the call control parameters sent towards the external network shall be set according to 
the setting for multimedia calls, and TMR is set to "64 kbit/s unrestricted". The 3G-324.M codec shall be returned to the 
originating MSC server as the selected codec and be the only member of the available codec list. 

NOTE 2: For multimedia calls, 3GPP TS 27.001 [5], annex B, and 3GPP TS 29.007 [6], table 7A, describe the 
setting and validity of the PLMN BC-IE as well as the comparable settings of parameters in the PLMN 
and ISDN BC-IEs. As the ISDN BC-IE parameter values used for UDI/RDI multimedia calls are identical 
to the BICC USI IE parameter values (see 3GPP TS 29.205 [7]), the setting of call control parameters 
sent towards the external network in case of fallback to multimedia can be derived straightforward. 
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If fallback to speech occurs, the call control parameters shall be set according to the setting for speech calls, and TMR is 
set to "speech". The 3G-324.M codec shall be removed from the available codec list. Speech codec selection shall be 
made according to normal OoBTC procedures for interworking to external networks, and the selected codec and 
available codec list returned to the originating MSC server. 

4.3.9 User interaction and in-band information 

The MSC provided announcements and tones do not work, if the negotiated BC is a multimedia EC. Most often the in- 
band information is connected to the originating UE but the same rules apply for the terminating UE. The following 
rules apply: 

1) Before sending the CONNECT message the originating MSC may insert in-band information if CALL 
PROCEEDING message indicates speech as the selected or preferred service. When fallback to 
multimedia occurs after CALL PROCEEDING but before CONNECT, the MSC may insert in-band 
information. 

2) Before sending the CONNECT message the originating MSC shall not insert in-band information, if 
CALL PROCEEDING message indicates multimedia as the selected or preferred service. When fallback 
to speech occurs after CALL PROCEEDING but before CONNECT, the MSC shall not insert in-band 
information. 

3) After the CONNECT message to/from the UE the originating/terminating MSC may insert in-band 
information, if the selected service is speech. Otherwise, the MSC shall not insert any in-band 
information. As an option, if the call is to be cleared, the MSC may perform an in-call modification to 
speech prior to the insertion of the in-band information. 

4) During the call setup phase the terminating MSC, transit MSC and GMSC may insert in-band 
information, if the selected/preferred service received from the originating switch is speech. Otherwise 
the terminating MSC, transit MSC and GMSC shall not insert any in-band information during the call 
setup phase. 

5) In the active phase of the call the terminating MSC, transit MSC and GMSC may insert in-band 
information, if the selected service is speech. Otherwise the terminating MSC, transit MSC and GMSC 
shall not insert any in-band information. As an option, if the call is to be cleared, the terminating MSC, 
transit MSC or GMSC may perform an in-call modification to speech prior to insertion of the in-band 
information. 



Lawful Interception 



SCUDIF calls shall be monitored as for normal Circuit Switched data calls, for detailed requirements see 3GPP TS 
33.106 [9]. 
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